Concepts for viewing and accessing claim versions

ABSTRACT

Systems, methods, apparatus, and computer program products are provided for accessing, navigating, and displaying multiple versions of claims in an efficient and customer-friendly manner. In various embodiments, claims can be processed and stored such that they can be displayed via an interface in a graphical format (e.g., textual, circular, hierarchical, etc.).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/434,367 filed on Mar. 29, 2012, the entirety of which is hereinincorporated by reference.

BACKGROUND

Generally, claims systems are very complex. For example, claims paymentsystems often process a high volume of claims in accordance with dynamicmedical policies, payment policies, contract terms, and benefit plans.Accordingly, processing claims can be equally complex and result invarious claim versions that end with a claim being modified, denied, orpaid. Thus, a need exists for accessing, navigating, and displayingmultiple versions and iterations of claims and information about thoseclaim versions in an efficient and customer-friendly manner.

BRIEF SUMMARY

In general, embodiments of the present invention provide systems,methods, apparatus, and computer program products for accessing,navigating, and displaying multiple versions of claims in an efficientand customer-friendly manner.

In accordance with one aspect, a method is provided. In one embodiment,the method comprises (1) receiving a claim; (2) storing the claim (a) asa first version of the claim, (b) in association with a date and a time,(c) in association with an external claim identifier, and (d) inassociation with a first internal claim identifier corresponding to thefirst version of the claim; (3) processing the claim in accordance withone or more claims processing rules; and (4) storing the processed firstversion of the claim as a second version of the claim, wherein thesecond version of the claim is stored in association with (a) a date anda time the first version of the claim was processed, (b) the externalclaim identifier, and (c) the first internal claim identifiercorresponding to the first version of the claim.

In accordance with another aspect, a computer program product isprovided. The computer program product may comprise at least onecomputer-readable storage medium having computer-readable program codeportions stored therein, the computer-readable program code portionscomprising executable portions configured to (1) receive a claim; (2)store the claim (a) as a first version of the claim, (b) in associationwith a date and a time, (c) in association with an external claimidentifier, and (d) in association with a first internal claimidentifier corresponding to the first version of the claim; (3) processthe claim in accordance with one or more claims processing rules; and(4) store the processed first version of the claim as a second versionof the claim, wherein the second version of the claim is stored inassociation with (a) a date and a time the first version of the claimwas processed, (b) the external claim identifier, and (c) the firstinternal claim identifier corresponding to the first version of theclaim.

In accordance with yet another aspect, an apparatus comprising at leastone processor and at least one memory including computer program code isprovided. In one embodiment, the at least one memory and the computerprogram code may be configured to, with the processor, cause theapparatus to at least (1) receive a claim; (2) store the claim (a) as afirst version of the claim, (b) in association with a date and a time,(c) in association with an external claim identifier, and (d) inassociation with a first internal claim identifier corresponding to thefirst version of the claim; (3) process the claim in accordance with oneor more claims processing rules; and (4) store the processed firstversion of the claim as a second version of the claim, wherein thesecond version of the claim is stored in association with (a) a date anda time the first version of the claim was processed, (b) the externalclaim identifier, and (c) the first internal claim identifiercorresponding to the first version of the claim.

In accordance with still another aspect, a method is provided. In oneembodiment, the method comprises (1) receiving a first version of aclaim; (2) storing the first version of the claim in association with(a) a date and a time, (b) an external claim identifier, and (c) a firstinternal claim identifier corresponding to the first version of theclaim; (3) receiving a second version of the claim; and (4) storing thesecond version of the claim in association with (a) a date and a time,(b) the external claim identifier, and (c) a second internal claimidentifier corresponding to the second version of the claim.

In accordance with another aspect, a computer program product isprovided. The computer program product may comprise at least onecomputer-readable storage medium having computer-readable program codeportions stored therein, the computer-readable program code portionscomprising executable portions configured to (1) receive a first versionof a claim; (2) store the first version of the claim in association with(a) a date and a time, (b) an external claim identifier, and (c) a firstinternal claim identifier corresponding to the first version of theclaim; (3) receive a second version of the claim; (4) store the secondversion of the claim in association with (a) a date and a time, (b) theexternal claim identifier, and (c) a second internal claim identifiercorresponding to the second version of the claim.

In accordance with yet another aspect, an apparatus comprising at leastone processor and at least one memory including computer program code isprovided. In one embodiment, the at least one memory and the computerprogram code may be configured to, with the processor, cause theapparatus to at least (1) receive a first version of a claim; (2) storethe first version of the claim in association with (a) a date and atime, (b) an external claim identifier, and (c) a first internal claimidentifier corresponding to the first version of the claim; (3) receivea second version of the claim; (4) store the second version of the claimin association with (a) a date and a time, (b) the external claimidentifier, and (c) a second internal claim identifier corresponding tothe second version of the claim.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Having thus described the invention in general terms, reference will nowbe made to the accompanying drawings, which are not necessarily drawn toscale, and wherein:

FIG. 1 is an overview of a system according to various embodiments ofthe present invention.

FIG. 2 is an exemplary schematic diagram of a claims system according toone embodiment of the present invention.

FIG. 3 is a flowchart illustrating operations and processes that can beused in accordance with various embodiments of the present invention.

FIGS. 4-14 show exemplary input and output that can be used inaccordance with various embodiments of the present invention.

DETAILED DESCRIPTION

Various embodiments of the present invention now will be described morefully hereinafter with reference to the accompanying drawings, in whichsome, but not all embodiments of the inventions are shown. Indeed, theseinventions may be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein; rather, theseembodiments are provided so that this disclosure will satisfy applicablelegal requirements. The term “or” is used herein in both the alternativeand conjunctive sense, unless otherwise indicated. The terms“illustrative” and “exemplary” are used to be examples with noindication of quality level. Like numbers refer to like elementsthroughout.

I. METHODS, APPARATUS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS

As should be appreciated, various embodiments may be implemented invarious ways, including as methods, apparatus, systems, or computerprogram products. Accordingly, various embodiments may take the form ofan entirely hardware embodiment or an embodiment in which a processor isprogrammed to perform certain steps. Furthermore, variousimplementations may take the form of a computer program product on acomputer-readable storage medium having computer-readable programinstructions embodied in the storage medium. Any suitablecomputer-readable storage medium may be utilized including hard disks,CD-ROMs, optical storage devices, or magnetic storage devices.

Various embodiments are described below with reference to block diagramsand flowchart illustrations of methods, apparatus, systems, and computerprogram products. It should be understood that each block of the blockdiagrams and flowchart illustrations, respectively, may be implementedin part by computer program instructions, e.g., as logical steps oroperations executing on a processor in a computing system. Thesecomputer program instructions may be loaded onto a computer, such as aspecial purpose computer or other programmable data processing apparatusto produce a specifically-configured machine, such that the instructionswhich execute on the computer or other programmable data processingapparatus implement the functions specified in the flowchart block orblocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including computer-readableinstructions for implementing the functionality specified in theflowchart block or blocks. The computer program instructions may also beloaded onto a computer or other programmable data processing apparatusto cause a series of operational steps to be performed on the computeror other programmable apparatus to produce a computer-implementedprocess such that the instructions that execute on the computer or otherprogrammable apparatus provide operations for implementing the functionsspecified in the flowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrationssupport various combinations for performing the specified functions,combinations of operations for performing the specified functions, andprogram instructions for performing the specified functions. It shouldalso be understood that each block of the block diagrams and flowchartillustrations, and combinations of blocks in the block diagrams andflowchart illustrations, can be implemented by special purposehardware-based computer systems that perform the specified functions oroperations, or combinations of special purpose hardware and computerinstructions.

II. EXEMPLARY SYSTEM ARCHITECTURE

FIG. 1 provides an illustration of a system that can be used inconjunction with various embodiments of the present invention. As shownin FIG. 1, the system may include one or more claims systems 100, one ormore networks 105, and one or more customer computing entities 110. Eachof the components of the system may be in electronic communication with,for example, one another over the same or different wireless or wirednetworks including, for example, a wired or wireless Personal AreaNetwork (PAN), Local Area Network (LAN), Metropolitan Area Network(MAN), Wide Area Network (WAN), or the like. Additionally, while FIG. 1illustrates the various system entities as separate, standaloneentities, the various embodiments are not limited to this particulararchitecture.

1. Exemplary Claims System

FIG. 2 provides a schematic of a claims system 100 according to oneembodiment of the present invention. In general, the term “system” mayrefer to, for example, any computer, computing device, mobile phone,desktop, tablet, notebook or laptop, database management system,distributed system, server, blade, gateway, switch, processing device,or combination of processing devices adapted to perform the functionsdescribed herein.

As will be understood from FIG. 2, in one embodiment, the claims system100 may include a processor 205 that communicates with other elementswithin the claims system 100 via a system interface or bus 261. Theprocessor 205 may be embodied in a number of different ways. Forexample, the processor 205 may be embodied as a processing element,processing circuitry, a coprocessor, a controller or various otherprocessing devices including integrated circuits such as, for example,an application specific integrated circuit (ASIC), a field programmablegate array (FPGA), a hardware accelerator, and/or the like.

In an exemplary embodiment, the processor 205 may be configured toexecute instructions stored in memory or otherwise accessible to theprocessor 205. As such, whether configured by hardware or softwaremethods, or by a combination thereof, the processor 205 may represent anentity capable of performing operations according to embodiments of thepresent invention when configured accordingly. For example, as discussedin more detail below, the claims system 100 may be configured, amongother things, to process and analyze claims. A display/input device 264for receiving and displaying data may also be included in (or incommunication with) the claims system 100. This display device/inputdevice 264 may be, for example, a keyboard or pointing device that isused in combination with a monitor (e.g., an electronic screen/display).The display/input device 264 may be a touchscreen that can detect thepresence and location of a touch within the display area. The claimssystem 100 may further include transitory and non-transitory memory 263,which may include both random access memory (RAM) 267 and read onlymemory (ROM) 265. The claims system's ROM 265 may be used to store abasic input/output system (BIOS) 226 containing the basic routines thathelp to transfer information to the different elements within the claimssystem 100.

In addition, in one embodiment, the claims system 100 may include atleast one storage device 268, such as a hard disk drive, a CD drive,and/or an optical disk drive for storing information on variouscomputer-readable media. The storage device(s) 268 and its associatedcomputer-readable media may provide nonvolatile storage. Thecomputer-readable media described above could be replaced by any othertype of computer-readable media, such as embedded or removablemultimedia memory cards (MMCs), secure digital (SD) memory cards, MemorySticks, electrically erasable programmable read-only memory (EEPROM),flash memory, hard disk, and/or the like. Additionally, each of thesestorage devices 268 may be connected to the system bus 261 by anappropriate interface.

Furthermore, a number of executable instructions, applications, scripts,program modules, and/or the like may be stored by the various storagedevices 268 and/or within RAM 267. Such executable instructions,applications, scripts, program modules, and/or the like may include anoperating system 280, a receiving module 270, a processing module 260,and a displaying module 250. As discussed in more detail below, theseexecutable instructions, applications, program modules, and/or the likemay control certain aspects of the operation of the claims system 100with the assistance of the processor 205 and operating system280—although their functionality need not be modularized. In addition tothe program modules, the claims system 100 may store or be incommunication with one or more databases, such as database 240 storingclaims processing rules, claims, and/or other functionality that can beenabled and/or disabled.

Also located within the claims system 100, in one embodiment, is anetwork interface 274 for interfacing with various computing entities,including a print computing entity. This communication may be via thesame or different wired or wireless networks (or a combination of wiredand wireless networks). For instance, the communication may be executedusing a wired data transmission protocol, such as fiber distributed datainterface (FDDI), digital subscriber line (DSL), Ethernet, asynchronoustransfer mode (ATM), frame relay, data over cable service interfacespecification (DOCSIS), or any other wired transmission protocol.Similarly, the claims system 100 may be configured to communicate viawireless external communication networks using any of a variety ofprotocols, such as 802.11, general packet radio service (GPRS),Universal Mobile Telecommunications System (UMTS), Code DivisionMultiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband CodeDivision Multiple Access (WCDMA), Time Division-Synchronous CodeDivision Multiple Access (TD-SCDMA), Long Term Evolution (LTE), EvolvedUniversal Terrestrial Radio Access Network (E-UTRAN), Evolution-DataOptimized (EVDO), High Speed Packet Access (HSPA), High-Speed DownlinkPacket Access (HSDPA), IEEE 802.11 (Wi-Fi), 802.16 (WiMAX), ultrawideband (UWB), infrared (IR) protocols, Bluetooth™ protocols, wirelessuniversal serial bus (USB) protocols, and/or any other wirelessprotocol.

It will be appreciated that one or more of the claims system's 100components may be located remotely from other claims system 100components. Furthermore, one or more of the components may be combinedand additional components performing functions described herein may beincluded in the claims system 100.

2. Exemplary Customer Computing Entity

Embodiments of the present invention may involve the use of one or morecustomer computing entities 110. Generally, the term “computing entity”may refer to, for example, any computer, computing device, mobile phone,desktop, tablet, notebook or laptop, database management system,distributed system, server, blade, gateway, switch, processing device,or combination of processing devices adapted to perform the functionsdescribed herein. Further, the customer computing entity may refer to acomputing entity associated with a doctor, a hospital, a pharmacy, aninsurance provider, a care manager, and/or other healthcare-relatedentities or professionals.

As will be recognized, the customer computing entity 110 may includecomponents similar to those described with regard to the claims system100. For example, the customer computing entity 110 may comprise: (1) aprocessor that communicates with other elements via a system interfaceor bus; (2) a display device/input device; (3) memory including both ROMand RAM; (4) a storage device; and (5) a network interface. Similarly, acustomer computing entity 110 may comprise executable instructions,applications, scripts, program modules, and/or the like. As will berecognized, these architectures are provided for exemplary purposes onlyand are not limited to the various embodiments.

III. EXEMPLARY SYSTEM OPERATION

Reference will now be made to FIGS. 3-14. FIG. 3 is a flowchartillustrating operations and processes that may be performed foraccessing, navigating, and displaying multiple versions of claims in anefficient and customer-friendly manner. FIGS. 4-14 show exemplary inputand output that can be used in accordance with various embodiments ofthe present invention.

1. Original Customer-Submitted Claims

In one embodiment, the process may begin at Block 300 of FIG. 3 with theclaims system 100 receiving (e.g., via the receiving module 270) anoriginal customer-submitted claim from a customer computing entity 110(e.g., via a customer operating the same). An originalcustomer-submitted claim may refer to the initial or first submission ofa claim by a customer. As will be recognized, a claim may be a requestfor payment/reimbursement for services rendered, materials used,equipment provided, and/or the like. For example, a claim may be arequest for payment/reimbursement for a consultation with a primary caredoctor, a medical procedure or an evaluation performed by an orthopedicsurgeon, a laboratory test performed by a laboratory, durable medicalequipment provided to an injured patient, medications or other materialsused in the treatment of a patient, and/or the like. As will berecognized though, embodiments of the present invention may be appliedto a variety of other settings, such as automotive claims, repairclaims, and/or the like.

In one embodiment, for each original customer-submitted claim receivedby the claims system 100, the claims system 100 can also receive aunique external claim identifier assigned to the claim. The externalclaim identifier can be used by a customer (e.g., operating a customercomputing entity 110) to access the claim (see FIGS. 7 and 11). Theclaims system 100 can also assign a unique internal claim identifier tothe claim. The internal claim identifier may be used by the claimssystem 100 to store certain versions of the claim in association withone another. As will be recognized, claim identifiers may be alphabetic,numeric, and/or alphanumeric characters and/or strings that can be usedas keys (e.g., primary keys and foreign keys) of a database. Forinstance, FIG. 4 shows two original customer-submitted claims. The firstoriginal customer-submitted claim is assigned 111098467234 as theexternal claim identifier and ACF4203 as the internal claim identifier.The second original customer-submitted claim assigned PROF01 as theexternal claim identifier and BXW6894 as the internal claim identifier.After being assigned claim identifiers, the claims system 100 can storeeach claim as a record in a database (Block 305 of FIG. 3).

As part of storing a claim as a record (see FIG. 4), each record mayinclude a claim version name field that indicates a textual descriptionof the type of version of claim to which the record corresponds. Thedifferent claim version names or version types may include, for example,original customer-submitted claims, revised customer-submitted claims,replaced customer-submitted claims, paid customer-submitted claims,internal claims, and/or the like. The claims system 100 can populate theclaim version name field with the appropriate information for each claimversion. To do so, the claims system 100 can determine what name toassociate with each version by, in part, determining whether any relatedclaims are currently being stored for the corresponding external claimidentifier. For instance, when the claims system 100 receives acustomer-submitted claim with an external claim identifier of111098467234, the claims system 100 can determine whether any claimsexist with an external claim identifier of 111098467234. If no claimversions exist with the external claim identifier of 111098467234, theclaims system 100 can populate the claim version name field withoriginal customer-submitted claim—indicating that it is the firstversion of the claim. Additionally, the claims system 100 can time stampthe time the version was created, such as the time the originalcustomer-submitted claim was created. As shown in FIG. 4, the originalcustomer-submitted version of claim 111098467234 was received on Dec.14, 2013, at 12:00:00 pm and time stamped as 2013-12-14 12:00:00. Theoriginal customer-submitted version of claim PROF01 was received on Jan.27, 2014, at 12:59:43 pm and time stamped as 2014-01-27 12:59:43.

Further, as also shown in FIG. 4, the record for each claim may includea current claim field that can be populated with a “Y” or an “N.” Thecurrent claim field can be used to indicate the most-recent version orcurrent version of a claim. Thus, until an original customer-submittedclaim is processed, its corresponding current version field can bepopulated with a “Y” indicating that the record is the most-recentversion or current version of the claim. Once the claims system 100processes the original customer-submitted claim in accordance with theappropriate claims processing rules, the claims system 100 maycreate/generate a new record for the processed version of the claim andpopulate the current claim field of the new record with a “Y.”Correspondingly, the claims system 100 can then populate the currentclaim field in the record for the original customer-submitted claim thatwas just processed with an “N,” indicating that it is no longer thecurrent version of the claim. Thus, each time a new version (e.g.,record) of a claim is created, the claims system 100 can update theappropriate current claim fields to indicate which record is themost-recent version or current version of the claim (Block 305 of FIG.3).

Although not shown, in one embodiment, the record for each claim mayalso include information related to a claim header. An exemplary claimheader is shown in FIGS. 8-10 and 12. As seen in these figures, theclaim header may include information associated with the patient, suchas the patient's name, identification number, date of birth, gender,address, medical record number, assigned physicians, and/or the like.The claim header may also include provider information, such as theprovider's name, contract number, certifications, identification number,address, license numbers, and/or the like. In one embodiment, the claimheader can be shown in a claim header panel that can be expanded and/orreduced.

In one embodiment, in addition to a claim header, the record for eachclaim may include information related to one or more lines of a claim.Exemplary claim lines are shown in FIGS. 8-10 and 12. As seen in thesefigures, a line may be a request for payment/reimbursement for servicesrendered, materials used, and/or equipment provided for one or moredates of service. Thus, each line may correspond to at least one codethat is used to request payment/reimbursement for the correspondingservice, material, and/or equipment. Such codes may be CurrentProcedural Terminology (CPT) codes, Healthcare Common Procedure CodingSystem (HCPCS) codes, and/or the like. By way of example, a patient mayvisit a doctor because of discomfort in his lower leg. During the visit,the doctor may examine the patient's lower leg, take an x-ray of thelower leg, and provide the patient with a compression stocking to wearon the lower leg as a result of the examination. An originalcustomer-submitted claim from such a visit may have three lines witheach line using a distinct billing code: billing code 99213; billingcode 73590; and billing code A6542. Billing code 99213 may be used torequest payment/reimbursement for the visit, examination, and evaluationof the patient. Billing code 73590 may be used to requestpayment/reimbursement for the x-ray of the leg. And billing code A6542may be used to request payment/reimbursement for the compressionstocking provided to the patient.

2. Processed Claims

In one embodiment, after receiving an original customer-submitted claim,the claims system 100 can process each line of the customer-submittedclaim in accordance with various claims processing rules. Claimsprocessing rules may be for pricing claims, scoring claims, auditingclaims, bundling claims, and/or the like. Claims processing rules mayalso be for enforcing various policies, guidelines, requirements,contractual terms, and/or the like. For example, the claims processingrules may be used to enforce provisions of a provider's contract,contracted payment/reimbursement amounts, covered services and equipmentof a benefit plan, copays, age limits, deductibles, and/or the like. Todo so, there may be a set of claims processing rules for each provider,for each benefit plan, for certain services and/or equipment, forcertain billing codes, combinations thereof, and/or the like.

In processing a claim, the claims system 100 (e.g., via the processingmodule 260) can apply the appropriate claims processing rules tocreate/generate a recommendation as to whether each line of a claimshould be paid, denied, and/or modified (e.g., recommended forpayment/reimbursement in a manner other than as requested). In oneembodiment, the original customer-submitted claim (e.g., claim version)is never changed. Rather, each time a claim version is processed, a newversion of the claim can be created/generated. The new claim version mayinclude a recommendation or justification as to whether and how theclaim should be paid, denied, or modified. As indicated, afterprocessing the lines of an original customer-submitted claim, the claimssystem 100 can store the processed version of the originalcustomer-submitted claim as a new record (Block 310 of FIG. 3). Theclaims system 100 can also populate the claim version name field for theprocessed version of the original customer-submitted claim with internalclaim name. The new record for the processed version of the originalcustomer-submitted claim may have the same external claim identifier asthe original customer-submitted claim. However, the claims system 100may also assign a unique internal claim identifier to the new record andstore the same in the appropriate field. The claims system 100 may alsostore a time stamp of when the original customer-submitted claim wasprocessed (e.g., in the date created field). Additionally, the claimssystem 100 may store the internal claim identifier of the originalcustomer-submitted claim in the record for the processed version of theclaim in the related internal claim identifier field. The claims system100 can also update the current claim field to indicate that the newrecord is the most-recent version or current version of the claim (Block320 of FIG. 3), while simultaneously removing the current claim fielddesignation from the previous version. That is, only one claim versioncan be current at any time and there must be at least one.

Continuing with the above example, as shown in FIG. 5, the claims system100 can process the first original customer-submitted claim (claim111098467234; internal claim identifier ACF4203) in accordance with oneor more claims processing rules (e.g., create/generate a recommendationto pay, deny, or modify the claim). In doing so, the claims system 100can create a new record for the processed version of the originalcustomer-submitted claim (e.g., including the recommendation)—the newrecord being assigned ACF4204 as the internal claim identifier. Theclaims system may populate the claim version name field with “internalclaim” to indicate that the corresponding record is that of a processedclaim version. The time stamp for the new record (internal claimidentifier ACF4204) may be 2013-12-14 12:01:00, indicating that theoriginal customer-submitted claim was processed by the claims system 100on Dec. 14, 2013, at 12:01:00 pm. Further, in the new record (internalclaim identifier ACF4204), the claims system 100 can populate therelated internal claim identifier field with the internal claimidentifier assigned to the original customer-submitted claim: ACF4203.By using the same external claim identifier for new record of theprocessed claim (external claim identifier 111098467234), the claimssystem 100 can identify and access all versions of the correspondingclaim (claim 111098467234). And by storing the internal claim identifierassigned to the original customer-submitted claim (internal claimidentifier ACF4203) in the related internal claim identifier field ofthe new record (internal claim identifier ACF4204), the two claimversions can be linked together in terms of their relationship to oneanother. Further, as shown in FIG. 5, the claims system 100 can updatethe two records (internal claim identifier ACF4203 and internal claimidentifier ACF4204) to indicate that the record associated with internalclaim identifier ACF4204 is now the most-recent version of currentversion of claim 111098467234.

Continuing to FIG. 6, the claims system 100 processes the claim versionassigned internal claim identifier ACF4204 on 2013-12-17 15:54:32. Theclaims system 100 then stores the processed version as a record assignedinternal claim identifier ACF4985. Similar to as described above, theclaims system 100 then populates the related internal claim identifierfield for the record assigned internal claim identifier ACF4985 with theinternal claim identifier of the previous version (internal claimidentifier ACF4204) and updates the current claim field by setting theACF2985 entry with Y and simultaneously setting the ACF4204 to N. Thisprocess can be repeated as many times as necessary.

Similarly, the claims system 100 can process the second originalcustomer-submitted claim (claim PROF01; internal claim identifierBXE6894) in accordance with one or more claims processing rules (e.g.,create/generate a recommendation to pay, deny, or modify the claim). Indoing so, the claims system 100 can create a new record for theprocessed version of the original customer-submitted claim (e.g.,including the recommendation)—the new record being assigned BXW6895 asthe internal claim identifier. The claims system 100 may populate theclaim version name field with “internal claim” to indicate that thecorresponding record is that of a processed claim version. The timestamp for the new record (internal claim identifier BXW6895) may be2014-01-27 12:59:43. Further, in the new record (internal claimidentifier BXW6895), the claims system 100 can populate the relatedinternal claim identifier field with the internal claim identifierassigned to the original customer-submitted claim: BXW6894. By using thesame external claim identifier for new record of the processed claim(external claim identifier PROF01), the claims system 100 can identifyand access all versions of the corresponding claim (claim PROF01). Andby storing the internal claim identifier assigned to the originalcustomer-submitted claim (internal claim identifier BXW6894) in relatedinternal claim identifier field of the new record (internal claimidentifier BXW6895), the two claim versions can be linked together interms of their relationship to one another. Further, as shown in FIG. 5,the claims system 100 can update the two records (internal claimidentifier BXW6894 and internal claim identifier BXW6895) to indicatethat the record associated with internal claim identifier BXW6895 is nowthe most-recent version or current version of claim PROF01.

As will be recognized, as shown in FIG. 6, each time the claims system100 processes a version of a claim (such as original customer-submittedclaim or a processed version of a claim), the described steps may berepeated. This allows for the relationship of the life cycle of a claimto be maintained.

3. Revised, Replaced, and Paid Customer-Submitted Claims

In one embodiment, when the claims system 100 receives a claim that ithas “seen” before (e.g., based on the external claim identifier), it canstore that customer-submitted claim as a replaced customer-submittedclaim version, regardless of whether or not the content of the claim(e.g., the values in any of the claim fields) has changed. Additionally,the claims system 100 can also receive, store, and process revisedcustomer-submitted claims, reversed customer-submitted claims, paidcustomer-submitted claims, and/or the like (Blocks 300, 305, 310, 320 ofFIG. 3). For example, a revised customer-submitted claim may be arevised claim that is being submitted to correct the CPT codes or HCPCScodes submitted via the original customer-submitted claim. Similarly, areplaced customer-submitted claim may be a replacement claim that isbeing submitted to replace the original customer-submitted claim. Andfinally, a paid customer-submitted claim may reflect how the claim wasactually paid/reimbursed. As will be recognized, for a given claim, eachrevised, replaced, and paid customer-submitted claim may use a commonclaim header and external claim identifier. Further, the claims system100 can store each customer-submitted claim as an individual record asdescribed above with regard to the original customer-submitted claim.Also, as has been previously described, these customer-submittedversions (replaced, revised, reversed, or paid) can be updated to be thecurrent version of that claim.

In one embodiment, as described above, the claims system 100 canpopulate the claim version name field with the appropriate informationfor each claim version. To do so, when a customer-submitted claim isreceived, the claims system 100 can determine what name should populatethe claim version name field. To do so, the claims system 100 candetermine whether any related claims are currently being stored for thecorresponding external claim identifier. For instance, when the claimssystem 100 receives a customer-submitted claim with an external claimidentifier of 111098467234, the claims system 100 can determine whetherany claims exist with an external claim identifier of 111098467234. If aclaim exists with the external claim identifier of 111098467234, theclaims system 100 can appropriately populate the claim version namefield with replaced customer-submitted claim, revised customer-submittedclaim, or reversed customer-submitted claim. In another embodiment, forclaim versions received via a paid workflow, the claims system 100 canpopulate the claim version name field with paid customer-submittedclaim.

In one embodiment, each of these customer-submitted claim versions usesa common external claim identifier to link these versions of the claim.This allows the claims system 100 to maintain the correspondingrelationships of the claim's life cycle. It should be noted, however,that related internal claim identifier field is not populated forcustomer-submitted claims. Rather, the related internal claim identifierfield is optionally populated when the claims system 100 processes anexisting claim version. As described above, when an existing claimversion is processed, the claims system 100 populates the relatedinternal claim identifier field with the internal claim identifier ofthe previous claim version that was processed and updates the currentclaim field.

Continuing with above example, FIG. 6 shows two claims: claim111098467234 and claim PROF01. Claim 111098467234 has a total of 11versions—four of which are customer-submitted and seven of which areinternal versions. The customer-submitted versions are the recordsassigned internal claim identifiers ACF4203, ACF5954, ACF6112, andACF6452. FIG. 6 also shows the records associated with differentprocessed versions (and their linkage) to these customer-submittedversions of the claim. As also shown in FIG. 6, the record assignedinternal claim identifier ACF6185 for claim 111098467234 is the currentclaim. In other words, it is the most-recent version of claim111098467234.

Claim PROF01, on the other hand, has a total of 2 versions—one of whichis customer-submitted version. As previously described, thecustomer-submitted version is assigned internal claim identifierBXW6894, and the processed version of that claim is assigned internalclaim identifier BXW6895. The record assigned internal claim identifierBXW6895 is also indicated as the current claim.

4. Display and Navigation of Claim Versions

In one embodiment, using the information from the records of the variousclaim versions, the claims system 100 can cause display (e.g., viadisplaying module 250) of the claim versions in a graphical format,display, representation, and/or similar words used hereininterchangeably, such as shown FIGS. 9 and 12. The graphical format mayinclude a variety of information and formats including textualinformation, linked lists, tree formats, circular information (e.g.,concentric circles), hierarchical information, tabular format, acombination thereof, and/or the like. For example, a customer (e.g.,operating a customer computing entity 110) may access the claims system100 and request information associated with a particular claim (seeFIGS. 7 and 11). In response to such a request, the claims system 100can cause display of information corresponding to the appropriate claimand claim versions. For example, the claims system 100 can cause displayof the number of claim versions in an expanded or reduced view of aclaim version panel of an interface (e.g., tab or window of anapplication including a browser). The claims system 100 can also causedisplay of expanded or reduced views of various other panels withinformation described above. Such panels may include a claim headerpanel, a claim line panel, and/or the like. In one embodiment, as adefault setting, such information may be displayed for the currentversion of a claim, as indicated by the current claim field in therecords for a given claim.

By way of example, as shown in FIG. 7, a customer (e.g., operating acustomer computing entity 110) may access the claims system 100 andrequest information associated with claim PROF01. In response to such arequest, the claims system 100 may query the database for all claimrecords associated with external claim identifier PROF01. In thisexample, the query of the database will return two records: the recordassigned internal claim identifier BXW6894 and the record assignedinternal claim identifier BXW6895. Because two records are returned inresponse to the query, the claims systems 100 can determine that thereare two claim versions for claim PROF01. The claims system 100 can thencause display of an indication that the claim has two versions, such ascausing display of “VERSIONS (2)” in the claim version panel (see FIGS.8-10). As shown in FIG. 8, the claims system 100 can also cause displayof information corresponding to the claim in the claim header panel, theclaim line panel, and/or the like. As indicated, the claims system 100may default to causing display of such information for the currentversion of the claim, which in this example corresponds to the recordassigned internal claim identifier BXW6895.

In one embodiment, a customer (e.g., operating a customer computingentity 110) can initiate expansion of the claim version panel. Inresponse to such a request, the claims system 100 can cause display in agraphical format (e.g., textual, circular, hierarchical, etc.) of thedifferent claim versions for the corresponding claim. In the aboveexample, as shown in the claim version panel of FIG. 9, the claimssystem 100 can cause display of a relationship graphically of thedifferent versions of claim PROF01. To do so, the claims system 100 cancause display of at least a portion of each customer-submitted claim ina separate column. For example, the claims system 100 can identify allcustomer-submitted claims that were returned in the query—based on theclaim version name field for instance. Then, the claims system 100 canorder the different customer-submitted claims in order from left toright, right to left, and/or the like based on their time stamps. Insuch an embodiment, the customer-submitted claim with the earliest timestamp would be in the left-most column, and the customer-submitted claimwith the latest time stamp would be in the right-most column. In theabove example, because there is only one customer-submitted claim, theclaims system 100 creates/generates a single column for the differentclaim versions.

Additionally, the claims system 100 can also cause display of anyversions corresponding to each customer-submitted claim in therespective columns. To do so, for each customer-submitted claim, theclaims system 100 can query the database to determine whether therelated internal claim identifier field of any record has as its valuethe internal claim identifier of the corresponding customer-submittedclaim. In this example, the claims system 100 queries whether therelated internal claim identifier field of any record has BXW6894 as itsvalue. In this case, because the record assigned internal claimidentifier BXW6895 has BXW6894 as its value in the related internalclaim identifier field, the query returns the record associated withinternal claim identifier BXW6895. The claims system 100 can then querywhether the related internal claim identifier field of any record hasBXW6895 as its value. In this case, because the record assigned internalclaim identifier BXW6895 is the last version of claim PROF01, the querydoes not return any results. Then, the claims system 100 can organizethe claim assigned internal claim identifier BXW6895 in graphicalrelation (e.g., textual, circular, hierarchical, etc.) to thecorresponding customer-submitted claim (see the claim version panel ofFIG. 9). The claims system 100 can then cause display of therelationship graphically and cause display of at least a portion of eachclaim version (e.g., date and time stamp information). This approachprovides the customer with display in a graphical format (e.g., textual,circular, hierarchical, etc.) of claim versions, such as shown in FIG.9.

In one embodiment, as shown in FIGS. 10 and 12, each claim version canbe opened in a tab, opened in a window, and/or the like in response to acustomer request (e.g., via a customer operating a customer computingentity 110). For instance, each version of a claim in the graphicalformat/display can be selected to be opened in a tab, window, and/or thelike to view information about the claim version. Once opened, thecorresponding tab or window may include information to provide the userwith an indication as to which claim version is being displayed in thewindow or tab, for instance (see the tabs in FIGS. 8-9 and 12-14).Further, although not shown in the figures, the claims system 100 canchange the graphical format/display to indicate which claim version isbeing displayed via the window or tab. For example, a portion of theclaim version in the graphical format/display can be bolded,highlighted, outlined, greyed-out, and/or the like to indicate whichclaim version is being displayed via the current tab or window. Further,as shown in FIG. 8, the claims system 100 can also cause display of anidentifier via the interface (e.g., window or tab) indicating whichclaim version is the current version of the claim using the values inthe current claim field. For example, the claims system 100 can causedisplay of a visual indication (e.g., superimpose a tag/icon on thecurrent claim) in the graphical format/display (e.g., textual, circular,hierarchical, etc.), the tab, or window. The tag/icon may read “Current”and be colored, bolded, outlined, and/or the like for identificationpurposes. As another example, the indication could also be as simple asthe current claim field name with the associated value of Y or N beingdisplayed.

Continuing with another example, as shown in FIG. 11, a customer (e.g.,operating a customer computing entity 110) may access the claims system100 and request information associated with claim 111098467234. Inresponse to such a request, the claims system 100 may query the databasefor all claim records associated with external claim identifier111098467234. In this example, the query of the database will return 11records: the records assigned internal claim identifiers ACF4203,ACF4204, ACF4985, ACF5001, ACF5954, ACF5955, ACF6007, ACF6112, ACF6452,ACF6184, and ACF6185. Because 11 records are returned in response to thequery, the claims systems 100 can determine that there are 11 claimversions for claim 111098467234. The claims system 100 can then causedisplay of an indication that the claim has 11 versions, such as causingdisplay of “VERSIONS (11)” in the claim version panel (see FIG. 12). Aspreviously described, the claims system 100 may default to causingdisplay of information for the current version of claim 111098467234,which in this example corresponds to the record assigned internal claimidentifier ACF6185.

In one embodiment, as described, the claims system 100 can cause displayin a graphical format (e.g., textual, circular, hierarchical, etc.) ofthe different claim versions for claim 111098467234. For example, theclaims system 100 can cause display of at least a portion of eachcustomer-submitted claim in a separate column. To do so, the claimssystem 100 can identify all customer-submitted claims that were returnedin the query—based on the claim version name field for instance. Then,the claims system 100 can order the different customer-submitted claimsin columns in order from left to right based on their time stamps. Insuch an embodiment, the customer-submitted claim with the earliest timestamp would be in the left-most column, and the customer-submitted claimwith the latest time stamp would be in the right-most column. In thisexample, there are four customer-submitted claims. Thus, the claimssystem 100 can order the four customer-submitted claims in four columns(see FIG. 12).

Further, the claims system 100 can also cause display of any versionscorresponding to each customer-submitted claim in the respectivecolumns. To do so, for each customer-submitted claim, the claims system100 can query the database to determine whether the related internalclaim identifier field of any record has as its value the internal claimidentifier of the corresponding customer-submitted claim. In thisexample, the claims system 100 queries whether the related internalclaim identifier field of any record has ACF4203 as its value (theinternal claim identifier value of the first customer-submitted claim).In this case, because the record assigned internal claim identifier hasACF4204 has ACF4203 as its value in the related internal claimidentifier field, the query returns the record associated with internalclaim identifier ACF4204. Then, the claims system 100 can query whetherthe related internal claim identifier field of any record has ACF4204 asits value. In this case, because the record assigned internal claimidentifier has ACF4985 has ACF4204 as its value in the related internalclaim identifier field, the query returns the record associated withinternal claim identifier ACF4985. The claims system 100 can continuethis recursive process until the last record associated with thecustomer-submitted claim is identified. This allows all versions of acustomer-submitted claim to be organized in a graphical format (e.g.,textual, circular, hierarchical, etc.) in a single column. As anotherexample, the indication could also be as simple as the current claimfield name with the associated value of Y or N being displayed.

In one embodiment, the claims system 100 can then perform the sameprocess for the customer-submitted claim to be displayed in the secondcolumn—the second customer-submitted claim based on the time stamps forclaim 111098467234. For example, the claims system 100 can query whetherthe related internal claim identifier field of any record has ACF5954 asits value (the internal claim identifier value of the secondcustomer-submitted claim). In this case, because the record assignedinternal claim identifier has ACF5955 has ACF5954 as its value in therelated internal claim identifier field, the query returns the recordassociated with internal claim identifier ACF5955. Then, the claimssystem 100 can query whether the related internal claim identifier fieldof any record has ACF5955 as its value. In this case, because the recordassigned internal claim identifier has ACF6007 has ACF5955 as its valuein the related internal claim identifier field, the query returns therecord associated with internal claim identifier ACF6007. The claimssystem 100 can continue this recursive process until the last recordassociated with the customer-submitted claim is identified. Further, theclaims system 100 can continue this process for each customer-submittedversion of claim 111098467234. The claims system 100 can then organizethe claim versions in a relationship graphically and cause display ofthe same (see FIG. 12).

For each version, the claims system 100 can cause display of importantdate and time information related to each version at a quick glance. Forexample, the columns and rows in FIGS. 9, 10, and 12 show the claim nameand the date and time the corresponding record was created/generated. Invarious embodiments, this allows all customer-submitted claims and theirrespective versions to be displayed in corresponding columns and rows ina customer-friendly format.

In one embodiment, the claims system 100 may display claim versions formigrated claims as well. To do so, each claim version may have its owncolumn since the related internal claim identifier field may not bepopulated for migrated data. In such an example, display in thegraphical format may have both customer-submitted claim versions at thetops of columns and internal versions at the tops of columns—there wouldbe no related versions displayed in those columns. In this example, itwould not be until or unless the claims system 100 creates a newinternal version that the relationships would be established and couldbe visible as described above. In yet another example, if the relatedinternal claim identifier field was not known when a claim wasprocessed, for example, but populated later upon an upgrade or adoptionof the claims system's 100 functionality, the related internal claimidentifier field may be populated using custom business logic. Oncepopulated, the claims system 100 can use the field to display suchinformation as described above. Further, a visual indication may also bedisplayed to indicate that the claim versions being displayed are frommigrated data.

As shown in FIG. 12 and previously discussed, claim versions can beopened in tabs, windows, and/or the like in response to a customerrequest (e.g., via a customer operating a customer computing entity110). Further, for each claim version opened in a tab or window, theclaims system 100 can cause display of a visual indication in thegraphical format (e.g., textual, circular, hierarchical, etc.) as towhich claim version is being displayed in the tab or window. Forexample, a portion of the claim version in the graphical format/displaycan be bolded, highlighted, outlined, greyed-out, and/or the like toindicate which claim version is being displayed via the current tab orwindow. Further, as shown in FIG. 12, the claims system 100 can alsocause display of an identifier via the interface (e.g., window or tab)indicating which claim version is the most-recent version or the currentversion of the claim using the values in the current claim field. Forexample, the claims system 100 can cause display of a visual indication(e.g., superimpose a tag/icon on the current claim) in the graphicalformat/display (e.g., textual, circular, hierarchical, etc.), the tab,or window. The tag/icon may read “Current” and be colored, bolded,outlined, and/or the like for identification purposes. As anotherexample, the indication could also be as simple as the current claimfield name with the associated value of Y or N being displayed.

As indicated above, in one embodiment, each claim version can be openedin a tab, opened in a window, and/or otherwise navigated in response toa customer request (e.g., via a customer operating a customer computingentity 110). However, in certain embodiments, it may be desirable toprevent a claim or a claim version from being accessed by certainparties. For example, it may be desirable to prevent employees fromviewing claim information of specific coworkers or all coworkers. To doso, the claims system 100 can prevent (e.g., lock out) certain users(e.g., based on their user profiles) from viewing information aboutspecific people, claims, claim versions, and/or the like. Thus, theclaims system 100 may not display specific types of information aboutcertain people, claims, claim versions, and/or the like based on userprofiles accessing the information. That is, the claims system 100 canfilter (not include) or mask (include but identifying fields are maskedor not visible, typically using a masking character like “#”) for lockedpeople, claims, and/or claim versions. Additionally, as shown in FIG.13, the claims system 100 can cause display in the graphical format(e.g., textual, circular, hierarchical, etc.) of an indication that aclaim version or a claim has been locked—such as the tag/icon shown inFIG. 13. As will be recognized, a variety of other approaches andtechniques can also be used to adapt to various needs and circumstances.

In one embodiment, the claims system 100 can also indicate what actions,for example, were performed on/for a given claim version. Such actionsmay include pricing, scoring, auditing, bundling, and/or the like. Forinstance, when the claims system 100 creates/generates a recommendationto pay a line of a claim, the claims system 100 can price the line inaccordance with the appropriate contracts, fee schedules, etc. Afterpricing a line or claim, the claims system 100 can populate a pricingfield in the corresponding record for the claim with a “Y” to indicatethat the line or claim version has been priced. This allows the claimssystem 100 to cause display in the graphical format/display (e.g.,textual, circular, hierarchical, etc.) of an indication that a line, aclaim version, or a claim has been priced—such as the tag/icon shown inFIG. 14. As will be recognized, a variety of other approaches andtechniques can also be used to adapt to various needs and circumstances,such as for claim scoring, auditing, bundling, and/or the like.

In various embodiments, the described approaches and techniques allowfor more effective and efficient research of a claim and understandingof the life of a claim. As will be recognized, various other techniquesand approaches can be used to adapt to different needs andcircumstances.

IV. CONCLUSION

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseinventions pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the inventions are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A method for viewing claim versions, the method comprising:receiving, via one or more processors, a first version of a claim;storing, via the one or more processors, the first version of the claimin association with (a) a date and a time, (b) an external claimidentifier, and (c) a first internal claim identifier corresponding tothe first version of the claim; receiving, via the one or moreprocessors, a second version of the claim; and storing, via the one ormore processors, the second version of the claim in association with (a)a date and a time, (b) the external claim identifier, and (c) a secondinternal claim identifier corresponding to the second version of theclaim.
 2. The method of claim 1 further comprising causing display (a)of at least a portion of the first version of the claim, (b) of at leasta portion of the second version of the claim, and (c) the relationshipbetween the first version of the claim and the second version of theclaim in a graphical format based at least in part on the external claimidentifier.
 3. The method of claim 2 further comprising indicating thesecond version of the claim as the current version of the claim.
 4. Themethod of claim 3 further comprising: processing the second version ofthe claim in accordance with one or more claims processing rules; andstoring the processed second version of the claim as a third version ofthe claim, wherein the third version of the claim is stored inassociation with (a) a date and a time the second version of the claimwas processed, (b) the external claim identifier, and (c) the secondinternal claim identifier corresponding to the second version of theclaim.
 5. The method of claim 4 further comprising indicating the thirdversion of the claim as the current version of the claim.
 6. The methodof claim 5 further comprising causing display (a) of at least a portionof the first version of the claim, (b) of at least a portion of thesecond version of the claim, (c) of at least a portion of the thirdversion of the claim, and (d) the relationship between the first versionof the claim, the second version of the claim, and the third version ofthe claim in a graphical format based at least in part on the externalidentifier and the second internal claim identifier.
 7. The method ofclaim 1 further comprising: receiving input requesting display ofinformation associated with the second version of the claim; and causingdisplay of the information associated with the second version of theclaim.
 8. The method of claim 1, wherein the graphical format indicatesthat the information associated with the second version of the claim isbeing displayed.
 9. The method of claim 1 further comprising populatinga claim version name field for the first version of the claim.
 10. Themethod of claim 1 further comprising: determining a total number ofclaim versions associated with the external claim identifier; andcausing display of the total number of claim versions associated withthe external claim identifier.
 11. The method of claim 1 furthercomprising causing display of an indication that the first version ofthe claim is locked.
 12. The method of claim 1 further comprisingcausing display of an indication that a specific action has beenperformed for the claim.
 13. A computer program product for viewingclaim versions, the computer program product comprising at least onenon-transitory computer-readable storage medium having computer-readableprogram code portions stored therein, the computer-readable program codeportions comprising: an executable portion configured to receive a firstversion of a claim; an executable portion configured to store the firstversion of the claim in association with (a) a date and a time, (b) anexternal claim identifier, and (c) a first internal claim identifiercorresponding to the first version of the claim; an executable portionconfigured to receive a second version of the claim; and an executableportion configured to store the second version of the claim inassociation with (a) a date and a time, (b) the external claimidentifier, and (c) a second internal claim identifier corresponding tothe second version of the claim.
 14. The computer program product ofclaim 13 further comprising an executable portion configured to causedisplay (a) of at least a portion of the first version of the claim, (b)of at least a portion of the second version of the claim, and (c) therelationship between the first version of the claim and the secondversion of the claim in a graphical format based at least in part on theexternal claim identifier.
 15. The computer program product of claim 14further comprising an executable portion configured to indicate thesecond version of the claim as the current version of the claim.
 16. Thecomputer program product of claim 15 further comprising: an executableportion configured to process the second version of the claim inaccordance with one or more claims processing rules; and an executableportion configured to store the processed second version of the claim asa third version of the claim, wherein the third version of the claim isstored in association with (a) a date and a time the second version ofthe claim was processed, (b) the external claim identifier, and (c) thesecond internal claim identifier corresponding to the second version ofthe claim.
 17. The computer program product of claim 1 furthercomprising an executable portion configured to indicate the thirdversion of the claim as the current version of the claim.
 18. Thecomputer program product of claim 17 further comprising an executableportion configured to cause display (a) of at least a portion of thefirst version of the claim, (b) of at least a portion of the secondversion of the claim, (c) of at least a portion of the third version ofthe claim, and (d) the relationship between the first version of theclaim, the second version of the claim, and the third version of theclaim in a graphical format based at least in part on the externalidentifier and the second internal claim identifier.
 19. The computerprogram product of claim 13 further comprising: an executable portionconfigured to receive input requesting display of information associatedwith the second version of the claim; and an executable portionconfigured to cause display of the information associated with thesecond version of the claim.
 20. The computer program product of claim13, wherein the graphical format indicates that the informationassociated with the second version of the claim is being displayed. 21.The computer program product of claim 13 further comprising anexecutable portion configured to populate a claim version name field forthe first version of the claim.
 22. The computer program product ofclaim 13 further comprising: an executable portion configured todetermine a total number of claim versions associated with the externalclaim identifier; and an executable portion configured to cause displayof the total number of claim versions associated with the external claimidentifier.
 23. The computer program product of claim 13 furthercomprising an executable portion configured to cause display of anindication that the first version of the claim is locked.
 24. Thecomputer program product of claim 13 further comprising an executableportion configured to cause display of an indication that a specificaction has been performed for the claim.
 25. An apparatus comprising atleast one processor and at least one memory including computer programcode, the at least one memory and the computer program code configuredto, with the processor, cause the apparatus to at least: receive a firstversion of a claim; store the first version of the claim in associationwith (a) a date and a time, (b) an external claim identifier, and (c) afirst internal claim identifier corresponding to the first version ofthe claim; receive a second version of the claim; and store the secondversion of the claim in association with (a) a date and a time, (b) theexternal claim identifier, and (c) a second internal claim identifiercorresponding to the second version of the claim.
 26. The apparatus ofclaim 25, wherein the memory and computer program code are furtherconfigured to, with the processor, cause the apparatus to cause display(a) of at least a portion of the first version of the claim, (b) of atleast a portion of the second version of the claim, and (c) therelationship between the first version of the claim and the secondversion of the claim in a graphical format based at least in part on theexternal claim identifier.
 27. The apparatus of claim 26, wherein thememory and computer program code are further configured to, with theprocessor, cause the apparatus to indicate the second version of theclaim as the current version of the claim.
 28. The apparatus of claim27, wherein the memory and computer program code are further configuredto, with the processor, cause the apparatus to: process the secondversion of the claim in accordance with one or more claims processingrules; and store the processed second version of the claim as a thirdversion of the claim, wherein the third version of the claim is storedin association with (a) a date and a time the second version of theclaim was processed, (b) the external claim identifier, and (c) thesecond internal claim identifier corresponding to the second version ofthe claim.
 29. The apparatus of claim 28, wherein the memory andcomputer program code are further configured to, with the processor,cause the apparatus to indicate the third version of the claim as thecurrent version of the claim.
 30. The apparatus of claim 29, wherein thememory and computer program code are further configured to, with theprocessor, cause the apparatus to cause display (a) of at least aportion of the first version of the claim, (b) of at least a portion ofthe second version of the claim, (c) of at least a portion of the thirdversion of the claim, and (d) the relationship between the first versionof the claim, the second version of the claim, and the third version ofthe claim in a graphical format based at least in part on the externalidentifier and the second internal claim identifier.
 31. The apparatusof claim 25, wherein the memory and computer program code are furtherconfigured to, with the processor, cause the apparatus to: receive inputrequesting display of information associated with the second version ofthe claim; and cause display of the information associated with thesecond version of the claim.
 32. The apparatus of claim 25, wherein thegraphical format indicates that the information associated with thesecond version of the claim is being displayed.
 33. The apparatus ofclaim 25, wherein the memory and computer program code are furtherconfigured to, with the processor, cause the apparatus to populate aclaim version name field for the first version of the claim.
 34. Theapparatus of claim 25, wherein the memory and computer program code arefurther configured to, with the processor, cause the apparatus to: anexecutable portion configured to determine a total number of claimversions associated with the external claim identifier; and anexecutable portion configured to cause display of the total number ofclaim versions associated with the external claim identifier.
 35. Theapparatus of claim 25, wherein the memory and computer program code arefurther configured to, with the processor, cause the apparatus to causedisplay of an indication that the first version of the claim is locked.36. The apparatus of claim 25, wherein the memory and computer programcode are further configured to, with the processor, cause the apparatusto cause display of an indication that a specific action has beenperformed for the claim.